home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000091_owner-urn-ietf _Sat Mar 29 03:07:14 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  5KB

  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id DAA10450
  3.     for urn-ietf-out; Sat, 29 Mar 1997 03:07:14 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id DAA10445
  6.     for <urn-ietf@services.bunyip.com>; Sat, 29 Mar 1997 03:07:06 -0500 (EST)
  7. Received: from beach.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA21294  (mail destined for urn-ietf@services.bunyip.com); Sat, 29 Mar 97 03:07:03 -0500
  9. Received: from beach.w3.org (beach.w3.org [207.8.37.250])
  10.           by beach.w3.org (8.8.4/8.8.4) with SMTP
  11.       id CAA16497; Sat, 29 Mar 1997 02:07:02 -0600
  12. Message-Id: <333CCDA4.4C4A6A24@w3.org>
  13. Date: Sat, 29 Mar 1997 02:07:00 -0600
  14. From: Dan Connolly <connolly@w3.org>
  15. Organization: World Wide Web Consortium
  16. X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i586)
  17. Mime-Version: 1.0
  18. To: Leslie Daigle <leslie@bunyip.com>
  19. Cc: urn-ietf@bunyip.com
  20. Subject: Rationale for urn: requested [was: [URN] draft-ietf-urn-nid-req-01.txt]
  21. References: <Pine.SUN.3.95.970328212322.13282G-100000@beethoven.bunyip.com>
  22. Content-Type: text/plain; charset=us-ascii
  23. Content-Transfer-Encoding: 7bit
  24. Sender: owner-urn-ietf@Bunyip.Com
  25. Precedence: bulk
  26. Reply-To: Dan Connolly <connolly@w3.org>
  27. Errors-To: owner-urn-ietf@Bunyip.Com
  28.  
  29. Leslie Daigle wrote:
  30. >If you have an idea of a specific
  31. > paragraph that belongs in a specific document, do _please_ make the
  32. > suggestion to the list.
  33.  
  34. I suggest that section 2. "Syntax" of
  35. ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-syntax-04.txt
  36.  
  37. reflect the rationale for the urn: prefix. I don't have specific
  38. wording to suggest because I don't understand the rationale.
  39.  
  40. Your message is the closest thing I've seen to evidence to
  41. support this design. (Thank you! Finally!) But...
  42.  
  43. > Specifically, there were people who said they _needed_ the syntactic
  44. > cue for their purposes  of using URNs, and no one who said they could
  45. > not deal with it.
  46.  
  47. Sigh... I can sympathize with this. I'm guilty of chairing
  48. enough meetings with this sort of compromise. But I really
  49. don't like it, and I want to be really sure that the
  50. choices were carefully considered, and that the resolution
  51. is explicitly written down in the specs.
  52.  
  53. > Some of the desire for having the syntactic cue are for resolution
  54. > reasons (e.g., being able to hand that _class_ of identifiers to a specific
  55. > proxy that knows about existing RDS's),
  56.  
  57. I find this idea of a urn: proxy worrisome: the intent of the
  58. URI design was that clients should be able to send _all_ unknown
  59. URI schemes to a "default proxy." That Netscape 2.x, for example,
  60. recognizes and proxies urn: but not isbn: is a hack and a kludge.
  61.  
  62.  
  63. > and some are for weighting
  64. > clues (e.g., prefer URNs to URLs).  _Yes_, you could keep a table fo which
  65. > identifier was which type, but that's an implementation answer, and does
  66. > not seem to be what general concensus said people wanted.
  67.  
  68. You can also keep these sorts of "hints" outside the identifier.
  69. For example, HTML has separate attributes for HREF= and URN=.
  70.  
  71. So I don't find any of that evidence compelling.
  72.  
  73. I haven't read the entire URN-WG archive, but I have read much
  74. of it, plus all of the following:
  75. ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-syntax-04.txt
  76. http://www.acl.lanl.gov/URN/http_res.txt
  77. http://www.bunyip.com/research/ietf/urn-bof/urnframework.txt
  78. http://www.netlib.org/utk/projects/rcds/rcds-tr/
  79.  
  80. and a bunch of other stuff, and I haven't found these
  81. implementors' claims that the urn: cue is necessary or even useful.
  82.  
  83.  
  84. > This issue was specifically brought up at the meeting in San Jose, and
  85. > was documented in the minutes.   See
  86. >         http://www.bunyip.com/research/ietf/urn-ietf/sanjose.txt
  87.  
  88. As I wrote in another message: I did that: but the minutes only
  89. state the conclusion. They don't give any of the evidence or reasons.
  90.  
  91. And anyway, in the IETF, the consensus at an IETF meeting
  92. isn't binding: all official business is conducted via email.
  93. (At least that's my understanding. Please correct me if
  94. I'm wrong.)
  95.  
  96.  
  97. > (by the way -- http://www.bunyip.com/research/ietf/urn-ietf  also
  98. > contains the text of the group's charter).
  99.  
  100. Thanks for the URL! I'd like to see a few more of them flying
  101. around here. Finding drafts etc. in email archives is kinda tedious.
  102.  
  103.  
  104. -- 
  105. Dan Connolly, W3C Architecture Domain Lead
  106. <connolly@w3.org> +1 512 310-2971
  107. http://www.w3.org/People/Connolly/
  108. PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21